All investigated incidents traced to authoritative identity data and how Workday attributes were provisioned into downstream systems. Resolutions involved correcting the user’s Workday record and completing any required HR/manager approval workflows; where Okta was in use the provisioning chain was Workday → Okta → Microsoft and Okta delivered the updated profile attributes into Microsoft 365, Teams and Outlook. Specific observations that resolved tickets included: • Preferred-name edits were prevented when Workday’s preferred-name field was locked by a checkbox; unlocking and updating that field (plus approvals) allowed the change to propagate. • Academic/professional titles stored in Workday’s job/position or other non-name fields produced unexpected or missing display values; moving or entering the title into the appropriate name/preferred-name field produced the expected display. • In at least one case a title existed for one campus/team but not another because the user had multiple account contexts/Teams app instances or team-specific provisioning; that scenario required coordination with local team/IT colleagues to reconcile or insert the title in the affected team context. • Direct edits made inside Microsoft or Teams were not authoritative and were reverted by the provisioned sync, so fixes were applied in Workday/HR. • Observed propagation windows varied: many updates appeared within 1–3 days while some systems took up to about two weeks to reflect the corrected display name/title. These combined factual findings resolved the matched tickets.

Authoritative identity and profile inconsistencies were corrected in Okta, Workday, and downstream systems; automation and manual edits were used depending on urgency and available tooling. Unwanted embedded titles and extraneous text were removed from Okta profiles; where a dedicated title attribute was unavailable salutation fields or EPOS surname fields were used to disambiguate external displays. Requested academic titles were added to canonical records and confirmed after normal directory propagation. Workday-driven canonical name changes were applied in Workday and Okta Workflows/automation then updated sign-in/UPN values; downstream systems adopted new values on their regular sync schedules. Administrators performed manual edits in Care/myCampus and similar systems when immediate corrections were required while waiting for upstream syncs. Conflicting, blocked, or duplicate emails that prevented self-service updates or propagation to Atlassian/Jira were cleared by removing or merging holding accounts so Okta could push the revised email; duplicate Care or external-contact records were merged into the intended profile when appropriate. External lecturer accounts were verified for active/inactive status; where accounts were active a password-reset link was sent to the provided private contact email when requested. Instances where private/personal email addresses were present in authoritative profiles were remediated by removing the private address from the central profile and applying fixes to myCampus and related services to stop notifications to personal addresses. Authentication problems specific to Atlassian were diagnosed and resolved in cases where users succeeded by using email instead of UID once email attributes were corrected. Approved automation and scripts (Atlassian API, Okta automation, Okta Workflows) performed edits and notifications where applicable; all changes propagated according to normal sync windows and were confirmed after propagation. Name-normalization rules in Okta Workflows were updated to include missing Unicode characters (for example the initial dotted capital 'İ') so names with those characters normalized correctly. For investigations involving third-party services, support checked license pools and ownership: an attempted unlink of a LinkedIn Learning/LinkedIn profile showed a private Microsoft–LinkedIn association owned outside IU control and no IU-managed license assignment was present, so IU support could not perform an unlink; users were informed of the external ownership and license-state findings. Inquiries about externally hosted Google accounts noted that Google accounts were not managed by central IT and membership could not be directly verified by IT; support confirmed this limitation and directed users to confirm ownership with the resource owner or follow service-specific access request paths (for example data-access forms) as appropriate.

Incidents were resolved according to where the authoritative data lived and where the stale view appeared. For display-name and title changes originating in central HR/profile systems (Workday, myCampus and similar) and flowing through identity providers (Okta) to Microsoft services, tickets were closed after backend synchronization and propagation windows completed and after any required approvals (for example manager approval in Workday) had processed. Typical observed propagation times for Workday→Okta→Microsoft chains were about 1–3 days, with occasional services taking up to ~2 weeks. Client-side cache behavior explained many perceived failures: Microsoft clients cached profile/display data locally and often continued to show old values until caches refreshed; simple application restarts frequently did not force an update, and in at least one case the Teams desktop client only displayed the updated name after the user signed out and signed back in. Changes could not be edited directly in Microsoft Office when the authoritative value resided in the HR/profile system. In the case of incorrect photos shown in public search results while the internal IU directory photo was correct, IT verified the internal profile and the resolution involved submitting a correction/report to the external search provider (Google) via its reporting portal; no internal IT changes were performed.

Changes entered the established approval workflows (Automation for Jira/Workday approval flows) and approvers were notified. After approvals, automation via Atlassian API and Okta updated the identity attributes (e.g., extended termination date), and confirmation messages were provided to requestors. These automated/approved updates completed the lifecycle change and were reflected in the identity directory.

The incident was resolved by rolling back the recently deployed feature that introduced the misconfigured rate limit. The rollback stopped the 429 responses and the cascading failure; incident remediation restored normal authentication, signup, profile retrieval, and password reset flows.

Support corrected the Okta Security Contacts entries by removing the personal/admin mailbox references and replacing them with the organisation's official security recipients. The change was coordinated with the Customer Success Manager and inbox checks were performed to confirm the listed addresses (including the central information security group address) had valid mailboxes and ownership. The Support page was updated to reflect the clarified primary security contacts and named recipients.

Technicians traced unexpected "email address changed" notifications to automated/background identity updates originating from HR/Workday or directory syncs and treated each provider accordingly. For Okta cases, the unintended primary email value was reverted to the original address (for example, htaylor@libf.ac.uk) and the account configuration was confirmed corrected; the user was informed of the restoration. For Apple-related notifications, staff confirmed the messages were expected as part of the Apple Federation Switch after the corporate email change, supplied the intranet SharePoint guidance, and recommended requesting a managed Business/Work Apple account through the Service-Portal when appropriate. In situations where a separate work Apple identity was required, a new iCloud email address was created to preserve separation of personal and work data; teams noted and communicated that Apple Business/federated accounts may not support migrating existing personal iCloud data to a managed account. Each incident resolution documented the source of the identity change (HR/Workday or directory sync), the corrective or explanatory action taken, and the user-facing outcome.

A persistent temporary Apple ID prompt on managed devices was resolved by signing the device out of the temporary Apple ID and replacing it with a private Apple ID (for example, an icloud.com address); after the replacement the device returned to normal operation. Sign‑in failures on devices under remote management were resolved when users authenticated with their institutional credentials (IU Study / IU email) as required by the management profile. A separate case where an Apple account update prompt repeatedly failed both on-device and via the Apple ID website was resolved during a remote Microsoft Teams support session; the ticket did not record the specific technical steps taken during that session.

The issue was resolved by opening the Jamf Connect menu‑bar item, selecting 'Connect', and completing the login through that Connect menu. After successfully authenticating via the Jamf Connect menu the error dialogs stopped and normal operation resumed.

Support granted the user explicit edit permissions for the Winback wiki page and notified them; access was confirmed by the user and no further issues were reported after a one-week follow-up.

Support instructed the user to use the web versions as a temporary workaround. The user re-authenticated and confirmed sign-in was restored. Support also verified the workstation's device activation status and confirmed activation was retained.

Support identified the owning teams and redirected the requests: SiteFusion issues were referred to the CfE-TEAQ support team with contact details and the CfE-TEAQ FAQ page (including an "Unable to Login" troubleshooting section), and UniPark access was escalated to the Library and Information Service (LIS). No additional local remediation was performed before handoff.